The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Broadband network access is now widely available. In general, subscribers to broadband service that is provided by a service provider use a network device, such as a broadband router or gateway, to connect a personal computer or other end station to the service provider's network and obtain service. Automatic network configuration provisioning systems are now available for use in generating and downloading sets of configuration instructions, or configuration files, for network devices that are deployed in the field to subscribers of services provided by service providers. Such provisioning can occur automatically, without requiring a subscriber to manually enter configuration commands, and without requiring a technician associated with a network service provider to visit the subscriber and configure the device.
In one example approach, a vendor manufactures of customer premises equipment (CPE) network devices, and “drop-ships” the CPEs to the premises of subscribers of a network service provider. The CPEs are shipped with a generic bootstrap configuration that is copied from or generated at the vendor based on a standard template or format specified by the service provider. When a subscriber installs and powers-up a CPE, under control of the bootstrap configuration the CPE uses an interface specified in the bootstrap configuration to contact a configuration server associated with the service provider. The configuration server downloads a permanent, application-specific configuration to the CPE, which executes the received configuration and begins normal operation.
Standardized, template-based configurations contain configuration commands that refer to line cards, modules and interfaces by a specific slot or chassis location. Thus, the use of standardized template configurations requires that all the target hardware devices have a known, fixed hardware configuration, uniform for all network subscribers, so that the configuration can contain proper fixed references to slot locations.
However, many network devices are now made using a modular architecture in which the location of line cards and other components may vary from device to device, and may vary among units of the same device model. As the slots on a modular device are identical, any type of line card can be plugged into any slot. Thus, the manufacturer can package one device with multiple line cards in many combinations. Typically network devices comprise a chassis that supports one or more line cards for processing ATM, serial, or Ethernet data. Each line card has one or more interfaces. Configuration commands determine specific functions of the interfaces. For example, in a bootstrap configuration template, a particular configuration command in the template may instruct the device to configure slot 1, interface 3 and configure it as a serial interface. A service provider may use the same template for 1,000 devices that are deployed to its subscribers. However, if the devices are modular and do not have a line card in slot 1, or the device has a card in that slot that cannot provide a serial interface, the template configuration will not work and the device cannot obtain its permanent configuration.
While the inventory within a device chassis is deterministic at time of shipping from manufacturing, line-cards or modules are manually placed in the chassis. Therefore, controlling which line-cards or modules ultimately are placed in which slots is a labor-intensive problem, subject to human error and has had no known cost-effective, scalable solution. Therefore, to date, there has been no way to automate the configuration of modularized network devices with templates.
In this scenario, past approaches to automatic provisioning have not met with success. For example, with modularized routers that use a template-based configuration that specifies a particular slot that does not actually contain a line card with a necessary interface, the router cannot connect to a configuration server or other management point. Now, however, with modularized devices and the increasing use of drop shipment to deliver devices directly to subscribers, service providers need an improved automated provisioning process that can still use configuration templates.
In one known approach, Nortel Networks offers a customized template mechanism residing in the network management domain that allows the administrator to specify that a configuration associated with a given line card will only occur if that line card is in its correct intended slot. Otherwise, a controlled failure is generated during the provisioning of the device and the administrator is notified. This approach does not address automation of deployment workflow.
Further, the large majority of modules and line cards that plug into Nortel devices are “dumb” and have no way of self-announcing themselves upon device power-up or insertion or removal of a device. Even the fewer number of newer intelligent cards simply self-announce physical attributes such as type of card and slot insertion point, but these attributes are inadequate to support automated provisioning of network devices. There is a need for a way to provide a high-level inventory event on-behalf of all cards in the device, including the set of device-wide absolute references to all physical interfaces that can be provisioned on each card. Further, there is a need to receive, at a management point, an inventory of unpopulated or empty slots within the device chassis. Having numerous other inventory details reported about each card would be beneficial. Such higher-level inventory information is essential to the automation of network management functions such as provisioning.
In another known approach, Cisco Systems, Inc. offers a “Config Express” service that allows customers to specify a device configuration that Cisco writes into each router or other device at manufacturing time. This service is available for fixed chassis routers only, and it cannot be extended to modular devices.
In another known approach, many cable modems of various vendors support a mechanism for automatically acquiring their configuration. However, such devices are not modular devices, and they need a TFTP agent server for the mechanism to work. Most service providers will not use TFTP protocols to communicate to subscriber CPE devices because of lack of security. Thus, there is a need for an approach that is compatible with secure protocols.
Further, the approach of some vendors such as Netility is to license imbedded technology to support automated communication of configuration information to devices. However, this approach does not support modular devices in which the location of line cards and modules may vary.
Based on the foregoing, there is a clear need for an approach for automatically provisioning of modular network devices.
There is a specific need for an approach that can use pre-specified configuration templates to deliver a consistent configuration to modular devices.
There is also a particular need for an automated configuration approach that is compatible with drop shipment practices.